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ABSTRACT 



This project develops a framework to permit the introduc- 
tion of combat effectiveness as a high level objective func- 
tion to the naval ship design process. This is effei ted by 
the development of a model of the sources of nission 
requirements for the design. Interaction and 
inter-connection of the design stages is provided by design- 
ing the model around the menu-oriented software system known 
as DEX (Decision Executive System). 

The model used the commonality of its’ design and the DEX 
commands and prompts as the means of insuring that all par- 
ticipants to the design process have access to the assump- 
tions used to develop combat effectiveness as an objective 
function. The possible capabilities of the model are exhib- 
ited through simple examples which show the extreme 
situation dependency of combat effectiveness assessments. 
The possible implications of the use of the model for future 
research in Naval Architecture/ Marine Engineering are dis- 
cussed. 
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CHAPTER 1 



INTRODUCTION TO THE PROBLEM 

The objective of this work was to establish a set of 
independent variables to describe a mono-hull surface 
combatant ship (naval vessel) and to determine its mission 
effectiveness. This determination will be made at the fea- 
sibility stage of the design and will be dependent upon the 
environment in which the design is to operate. It was 
determined that' all variables would be specified by their 
contribution to specific missions. It was expected that the 
determination of these contributions would eventually permit 
an evaluation of the designs' combat effectiveness. As in 
any large scale system definition, the question of appropri- 
ate level of detail was critical. This project will attempt 
to specify these independent variables, both in number and 
in detail, sufficiently to permit determination of: 



1. feasibility under known or assumed technological and 
budgetary constraints 

2. combat effectiveness 

3. non-combat mission effectiveness 

4. cost effectiveness. 
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Progress in the development of this set of independent 
variables was, initially, very uneven. The first problem 
was to establish a complete listing of all missions for such 
a ship. It was determinted that the best existing list of 
this sort would be a good point of departure for this prob- 
lem. Research toward finding such a document eventually 
lead to a publication entitled Naval Warfare Mission Areas 
and Required Operational Capability, also known as OPNAV 
Inst. 3501. 2E. This instruction is used to indicate which 
mission areas, of all possible U. S. Navy missions, have- 
been assigned to a particular class of vessels. It also 
lists the assigned missions by the portion of the ships' 
organization (operations, engineering, etc . ) which the 
mission is assumed to affect. As such, this instruction is 
an excellent attempt to describe all missions which a par- 
ticular ship is "expected" to be able to perform when 
properly (fully) manned and when all installed equipment is 
fully operational. 

The possible missions listed in OPNAV Inst. 3501. 2E could 
be broadly separated into two categories; combatant and 
non-combatant. Within this instruction, the descriptions of 
the two types of missions are quite different. A typical 
noncombat mission entry might be described as "Search and 
Rescue", with the the equipment and training levels for the 
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ship and crew being specified. Conversely, A typical combat 
mission entry might be "Force and Area Air Defense", and 
would generally be without any further explanation. 

This "underspecification" of many missions within this 
publication is most clearly shown in the listing of many 
general combat missions. In our previous examples of Force 
and Area Air Defense, the problem with the statement of the 
mission is that it is, in addition to being somewhat subjec- 
tive, very "relative". It is most relative to the forces 
which might be attempting to defeat the proposed defense. 
It is also dependent, among other things, upon which other 
ships are in company. In short, the whole mission area can 
only be defined in terms of a broad spectrum of possible 
situations . 

Since the non-combat mission area assignments in OPNAV 
Inst. 3501. 2E were considered satisfactorily specified, this 
publication was chosen as the basis for the selection of 
hardware resources necessary to perform those types of 
missions. The combat mission areas, however, were not 
defined well enough within that instruction to be used to 
determine the direct effect of the missions upon the ship 
and its' systems. Therefore, it was necessary to establish 
a methodology within the model which would permit sufficent 
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‘description of combat type missions. This framework was 
intended to provide that definition by allowing the mission 
to be described in terms of the operational environment 
within which the ship would be designed. This environment 
will include the contributions or detriments to combat 
effectiveness created by man-made and natural situations 
which the design might encounter in combat. Later, it was 
found that this "threat and environment" model would form 
the foundation for the evaluation of combat effectiveness of 
a ship. It must be kept in mind that both the platform and 
the payload were being, thusfar, described only in terms of 
what they must do. We were carefully avoiding any attempt 
to define the missions in terms of the means to be used to 
accomplish them. 

Now, we may address the various independent variables 
defining our theoritical ship in terms of the requirement 
but more importantly in terms of the source of the require- 
ment. The other two major sources of naval ship mission 
requirements were assumed to be; 1. Non-combat mission 
requirements - it was assumed that the requirements of OPNAV 
Inst 3501. IE satisfactorily listed these. 2. Estimated 
time/cost requirements; which might be considered a form of 
filter to the first level feasibility of the conceived pay- 
load. If all possible sources of the defining parameters 
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can be identified then we may be assured of addressing 
requirements in the construction of our model. To this 
point we have identified the types of vessel requirements as 



follows ; 




REQUIREMENT 


SOURCE 


--Combat Payload 


— Opponent, Environment, Fore 


+ 


in company 


— Non-Combat Payload 


— U. S. Navy (through society 



Equals "PAYLOAD" 



In the same vein; 




REQUI REMENT 


SOURCE 


— Payload 


— as above 


+ 


for payload 


--Platform Parameters 


— Naval Architect as 


Equals "SHIP"' 


per guidance provided 
by others 


The assumption made to this 


point is that, if the 



requirements of the different "sources" of ship character- 
istics could be clearly and completely defined, we could 
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translate these requirements into hardware; that is a ship. 
Even if we were entirely successful in this difficult trans- 
lation, we would be left with two important questions. 1. 
How "good" was the ship we had created? 2. What 
technique(s) could we use to permit timely processing and 
data manipulation of the numerous items which must be 
included in even the simplest of ships? 

The answer to the question of assessment of the "quality" 
of the designed ship depends in large measure, upon the 
assessors' definition of "goodness". In other words, it 
might well change with a change in assessor, with this in 
mind, the next logical step in the development of our model 
would be a tabulation of all significant measures of surface 
combatant vessel "performance". 

Previous ship synthesis models (we will roughly define 
SSMs as computer aided interconnection of the various ship 
design sub-stages) have focused upon the "non-combat" type 
performance measures. Toward the assessment of such items 
as cargo carrying capacity, rates and costs and even total 
"life cycle" costs, these models have made significant 
progress. In our case, we have, with the development of 
the combat situation framework, provided, in theory, the 
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information necessary to conduct a measurement of combat 
performance within the design process. 



Model Outline 

We can now look at the "flow chart" describing our 
approach to designing a Mono-hull surface combatant and the 
assessment of that design. See figure 1. 

As will be recalled, the general approach was to , first 
account for the different independent variables "driving" 
the design, by source. Referring to figure 1 these were; 



The environment in which it would perform the "combat" 
missions (la) 

The "non-combat" missions to be performed (lb) 

The material and financial resource considerations of 
both missions (Ic) 
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FIGURE 1 



The simple identification of these requirements is a nec- 
essary but not sufficient step in the total design of a ves- 
sel. We must, then identify the "blend” or "mixture" of the 
hardware items created by those requirements into a measure 
of "goodness" or more correctly a "measure of 
effectiveness". More precisely, we will look at the problem 
as a determination of the resultant effectiveness of a spe- 
cific combination of the variables. This determination was 
made using utility theory (see chapter 5) 

The major synthesis steps, as provided for in this model 
would be; 

Translation of mission requirements into a payload (Tl) 

Translation of platform parameters into a "ship" (T2) 

Estimation of the ship in terms of non-combat perform- 
ance (El) 

Estimation of the ship in terms of combat performance 
(E2) 

Model Design Philosophy 

Before describing the model in detail, we will discuss 
the "design philosophy" of the model. The following charac- 
teristics were determined to be the most important in the 
development of the model. 

1. "Performance" Based 

2. Computer based with the DEX software (see chapter 2) 
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Highest level development 



Performance Based 

Most existing ships synthesis models might be best described 
as the "one shot" method, where the objective becomes the 
satisfaction of a set of given requirements. These are usu- 
ally the ability to carry a certain amount of equipment, or 
perhaps, some type of vessel charactert ics such as geometry 
and powering. The problem with this type of approach is 
that the input is considered invioliate and the user can not 
regard any violation of assumptions made at an earlier stage 
of the design which lead to these conclusions. An associ- 
ated problem with this approach is that to reach such a 
state of specification the user most likely conducted much 
preliminary work prior to exercising the model. In short, 
much of the most involved design work has been conducted 
external to the possible assistance of the computational and 
data storage/retrevial abilities of the computer. A third 
problem common to most existing models is the virtual lack 
of interaction. The essentially batch or "one-shot" method 
used in most adequately-supported models requires the entire 
process to be repeated to discover the effect of any 
changes . 

As bothersome as the perviously described shortcomings to 

existing SSMs might be, the lack of adequate effectiveness 
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measurement is far more serious. Most common measurements 
are implicit co-relationships of displacement, fuel or man- 
ning levels to cost. Such variables are, indeed, important 
to the peace time portion of the life of the vessel. They 
do not, however, address the true reason for existance of 
the combatant, that is its performance in combat, itself. 
Historically such an assessment has , at best, been con- 
ducted totally separate from any non-combat performance 
evaluation. In the most common practice, any combat system 
design performance evaluation is conducted on a single sys- 
tem by system basis without any integration of the system 
resource requirements upon the vessel design. For example, 
the performance evaluation and resource requirement iden- 
tification for an anti-air missle system would not address 
any impact of those resources upon the performance of, say 
the anti-submarine weapons suite. In truth, the earliest 
time a total design is subjected to a combat performance 
analysis is usually after initial fleet introduction of the 
design. At this point the ship is "synthsized" according to 
its "major" characteristics and modeled by interested activ- 
ities. These models are then "gamed" against similarly 
conceptual izsed opponets. Two important points should be 
noted. First, this process is done after we have paid full 
price for the vessel without the opportunity to correct any 
discovered weaknesses prior to completion. Second, the 
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information of how the "modelers" "fought" the ship is not 
retained. 

It will be the implicit assumption of this effort that 
the proper assessment of a combatant ship design should 
include an internal estimation of "combat effectiveness". 

DEX as the computer software package 

Given the necessity for computer aid in the modeling of 
the complex ship design process, the choice of operating 
software becomes critical. The major characteristics of the 
DEX (Design Executive) system, chosen for this model, are 
included in chapter 2. Also included in that chapter are 
the effects of those DEX characteristics upon the capabili- 
ties of the model. 



Highest Level Development 

In the development of any model, the selection of the char- 
acteristics which will be used to describe the modeled enti- 
ty is critical. The challenge is to include all necessary 
characteristics and no unnecessary ones. In the development 
of this model, an attempt has been made to identify all 
those variables needed to formulate the problem at the fea- 
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sibility level. It is intended that the model provide for 
the inclusion of all variables which could, at this feasi- 
bility level, affect the evaluation of the designs' combat 
effectiveness. 
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CHAPTER TWO 



The Design Executive System (DEX) 

The methodology for this model was designed to be 
installed within the Design Executive System (DEX) under 
development at Massachusetts Institute of Technology and the 
University of Mighigan. DEX is a self-contained software 
package which is adaptable to almost any computer system 
supporting fortran. It provides a system for running task 
based programs, called "modules”. Primarily, DEX supports 
interactive programs and it provides this interaction by 
communication between five "parties". These parties are; 



1. 


The 


user 




2. 


The 


computer 




3. 


The 


computation 


program 


4. 


The 


source of the input 


5. 


The 


destination 


of the output 



The degree of active involvement with DEX is within the pre- 
rogative of the person writinj the particular application 
program. That is the "module author" may choose which DEX 
services to use 

There are five major characteristics of DEX; 

1. The user is in the design loop. 
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2. 



DEX allows the design process to be executed in more 
than one sequence. 



3. DEX 

4. DEX 

5. DEX 



"talks" to the user in plain english, 
is "forgiving", 

has multiple capabilities for input and output. 
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1. The user is in the design loop. The ship design spiral 
vividly demonstrates the strongly iterative nature of the 
ship design process. The ability to perform data manipu- 
lations to a specific point and, then, analyze those results 
to decide where or if to proceed is vastly preferrable to a 
"through-puf'operat ion . DEX enables the user to choose a 
new path, obtain new information or to edit and insert 
information before it is used within computation sections. 

2. DEX allows the design process to be executed in more than 
one sequence. This is accomplished by providing the user 
with a scheme for generatiog menus within his application 
program. The use of "menus” to provide the user with a 
range of choices of possible decision paths toward his goal. 
A menu is a list of options (with a current maximum of 12 
per menu) from which the user chooses to either define a 
data value or proceed to the next step of the operation. 

An example of a menu is included in figure 2. If the 
user desired to specify or identify a type of weapon from 
this menu, he would type in sufficient characters to unique- 
ly identify that weapon within that menu. Examples might be 
"t" for torpedo or "aa.m" for AA.msl. The subprogram would 
accept this choice, if valid, and execute the segment of the 
program that is logically associated with the menu choice. 
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to callinq 
sub program 



WEP.TYPE 




GUN 






GUN 






TYPE 


TORPEDO 






RANGE 


AA.MSL 






RATE 


ASU.MSL 






RELOADS 


ASW.MSL 








DONE 




— < 


DONE 



FIGURE 2 



If the entry is not valid, the user will be prompted, again, 

for an entry from the same menu. It is not necessary that 

the menu, itself, be displayed. If the user is familiar 

with the choices within the menu, he might be prompted to 

make a choice, from memory, by seeing displayed 

*enter an item from menu-wep. type 

If however, the user does not know the choices of this menu 
he could type 

$ display menu-wep. type 
to have the menu displayed by DEX. 

Note the use of "done" as the last menu item in figure 2. 
A sub program with a menu containing "done" returns to the 
sub program which called it only when "done" is selected. 
Without "done" the control of the program is automatically 
returned. Such a menu, therefore, can only have one choice 
made at a time. The user is free to choose menu item(s) as 
desired. This means there is no predetermined path through 
a group of related of "stringed" menus, the user specifies 
the path. 



19 



3. DEX talks to the user in plain english. The menus, mes- 
sages and questions to the user generated by DEX have been 
specifically designed to be as easily understood as 
possible. The instructions which the user must supply are 
intended to be as nearly "conversational" in nature as they 
could. All dialoge encountered by the user has also been 
standardized within the DEX modules as much as possible to 
reduce learning effort when using a new program. 

4. DEX is forgiving. Because of the extended "pathing" of 
DEX, there is considerably more "mental discipline" required 
in its' use. Because of this additional "thinking" the pos- 
sibility of error is also increased. These errors might 
range from inadvertently depressed keys, to errors in 
desired process. When existing sections of DEX and its 
library routines were developed, as many potential errors 
and corresponding diagnostic messages as possible were 
anticipated and included. When an error is detected control 
is always returned to the user for resolution of the error 
without inter rrupt ing the execution of DEX or the module. 

5. Multiple input-output capability. DEX is designed to 
permit communication between; 
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1. Data Bases 



2. Disk Files 

3. Terminal screen for alphanumeric characters or graphics 

In general, the DEX operating environment may be 
described as having a total of five "sources" of information 
and four information "destinations". The term "information" 
is used in preference to input or output to reflect the 
duality and inter-changability of these two processes. For 
this reason, the author will apply the term "information" to 
variables which might be input or output, as values having 
source or destination. 

The sources and destinations for information provided 
within the DEX operating environment are; 



1. DEX-created data bases 

2. The user via terminals using DEX routines to read or 

write alphanumer ics 

3. The user via terminals or plotters using graphics to 

read or create x-y co-ordinate plots 

4. Sequential files 

5. Module default (source only) 



21 







M 



I 





The user may use a different type of destination, as his 
source may use different sources for information. For exam- 



pie. 


the 


user might 


read information from 


multiple 


data 


bases 


and 


write the 


information to another 


terminal 


or a 


file 


or 


both. The 


only restriction is 


an essential 


out-growth 


of logic; 


a module can be directed toward 


only 



one source or destination at a time. 

As may be obvious, DEX offers considerable improvement in 
facilitation of interactive design process management. It 
is designed to be consistent and flexible, providing "room" 
for the required magnitude and differing forms of informa- 
tion, processes and paths required in modern ship design. 

An explanation of DEX sufficient to develop the reader 
into a proficient DEX user will not be included in this 
paper. An excellent reference toward that end, however, is 
An Investigation into the Use of Data Bases in 
Computer-Aided Design, by LT Richard Celotto, USN 1981. It 
will be necessary to describe the major terms used in the 
system to permit easy reference. 

DEX consists of three levels of programs: 

1. DEX proper- These several hundred subroutines provide 
the operating "umbrella" of DEX. These subroutines are 
designed to provide a uniform appearance of the system 
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to the user of the various modules. In general, they 
provide consistent input-output and data manupulation 
capabilities throughout the system. 

2. Extented DEX library- this is a collection of 45 subrou- 
tines and general functions designed to facilitate the 
construction of a module with a program specific 
purpose. These include; reading, writing, editing, unit 
conversion, and messages and status indications. 

3. Module- A module is a complete set of subprograms writ- 
ten and executed together to perform a specific task. 
It may only have one program or it may have many addi- 
tional subprograms employing menus to take full advan- 
tage of DEX and any extended library functions desired. 



One concept of DEX is critical. DEX identifies a vari- 
able within a data base by its name and not by its location. 
To use this capability, the data base must be properly con- 
structed by the use of the command in the DEX proper main 
menu "DBEDCMDS" or the data base management routines listed 
in Celoto pg 30. Once these format rules have been 
observed, arrangement of variables within the data base may 
be made without regard to sequence. Thus, for example, if a 
user needed the value in a data base corresponding to a 
ships length, he might retrieve that value at address 
"length". He would not have to specify (or know) that the 
desired value is in the fourth or tenth entry in the data 
base. This is a powerful and new approach and it ’permits a 
user unfamiliar with a specific data base to obtain included 
information with much less prompting instruction. 
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Another very important feature, a feature absolutely 
critical to an interactive process, is that it can be edited 
from within DEX but outside a user module. This capability 
allows the user to over-ride, if he desires, a program cre- 
ated result and input, directly, an alternative. 
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CHAPTER 3 



Section Development Example 

This chapter will outline the techniques used to develop 
the sections outlined in chapter 1. The section chosen for 
this explanation is "Threat and Environment". 

The initial work within each section was to research the 
general topic; in this case the natural operating environ- 
ment and the possible combat threats which our design might 
encounter in the performance of its assigned missions. In 
the beginning of the effort it was important to be alert to 
any and all information on the subject. Thus, the earliest 
work was directed to put the widest possible bounds about 
the area. In this early stage, the best source of these 
bounds was conversations with leading academic and profes- 
sional experts in the field. Other early sources included 
professional journals, proceedings of applicable societies 
and unclassified professional development publications for 
United States Naval officer warfare specialty qualf ication. 
In this section. We began with the three classic threats; 
air, surface, and sub-surface. Literature alerted us to the 
necessity to include la'nd based targets as a potential 
"threat". Later, conversations with "experts", especially 
"wargaming" types, proved that certain aspects of weather, 
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general jamming environment and the use of decoys were all 
matters which could have major impacts upon threat develop- 
ment. Through an involved iterative process the following 
seven areas of "environment and Threats" were proposed and 
accepted as inclusive. 

1. SURFACE- surface ship and mine threats 

2. SUBSURFACE- submarines, swimmers and submerged mines 

3. AIR- aircraft or missiles 

4. LAND- missile sites or cities 

5. JAMMING 

6 . DECOYS 

7. WEATHER- environment including temperature, seas, 
visability 

At this point, the first order parameters of the "Threat 
and Environment" had been identified. Attention was then 
directed toward specification of the independent variables 
defining each of these seven areas; the sub-elements, if you 
will. The process described for the determination of the 
threat environment was repeated, in scale, for the identifi- 
cation of the factors constituting each of them. 

The investigative method used in the detailed development 
of each section investigated in this report was: 
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1. An initial estimate of the elements was made. 

2. A literature review of both classified and un-classi f ied 
sources was conducted to provide a first refinement of 
the initial list. 

3. Private enterprise and military experts were consulted 
tofurther refine the list. 

4. The initial framework of the section was established. 

5. The team worked with the thesis advisor and contempories 
to confirm that the included elements had proved major 
impact upon the next higher level 

definition of our design. This work also ensured that 
the arrangement of the variables could be efficently 
implemented within the DEX framework. 

A discussion of what was, and perhaps just as 
importantly, what was not, included in this example section 
should be provided to demonstrate the process. In the case 
of overall combat situation definition, it was considered 
essential to include the elements which aided the ship, as 
well as the "threat". Therefore, this section would have to 
permit the presence and effect of friendly or aiding ships, 
aircraft or any other such elements as positive contrib- 
utions to the operating situation. It was decided to assume 
that, in the absence of information to the contrary, each 
side {them or us) had any capability known to be possessed 
by either. This is a conservative assumption but is impor- 
tant for several reasons: 

development of either side as a complete model, automat- 
ically models the opposition. 
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most operational commanders will make such an assumption 
in the employment and operation of their ships. 

In the case of our example section the next step after 
identification of the seven major areas was the identifica- 
tion of the subelements to each area. In the case of "air 
threats", the author's initial estimate of the appropriate 
subelements to "air threats" was: 



1. SPEED 

2. ALTITUDE 

3 . NUMBER 

4. SIZE 

5 . DECOYS 

From several visits to the U.S. Naval War College and 
from discussions with personnel in Washington, D.C. con- 
cerned with weapons system development and intergration, 
this list was modified as follows "speed" became two speeds; 
inflight speed - the normal "cruising" speed of the threat, 
and "terminal" or final speed of the threat as it made a 
final approach to the target (in this case us!). Although 
some weapons entire flight was conducted at a single speed, 
it is much more common for the majority of distance from 
launch to target to be conducted at the relatively low speed 
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to ensure a maximum range. Typically, the threat will then 
conduct a radical altitude change manuver such as a "pop up" 
from a low altitude approach or a "dive" from a high alti- 
tude approach to effect a high "terminal" speed attack upon 
its target. 

In addressing the problem of multiple targets, ("number" 
in the original list) it became quickly apparent that the 
threat could have density in both space and time. Thus, the 
type of "counter" mounted to raids of different sizes and 
time/spatial separation was quite different. These threats 
must be allowed to be accounted for separately or together. 

"Size" quickly proved to be a totally inadequate 
description "of the "visibility" of the threat to sensors and 
was quickly replaced by "signatures". Thus the list had 
changed, over a period of research and refinement as 
follows ; 



SPEED 



Air Threat Elements 

In flight speed 
Terminal speed 
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NUMBER 



Target density (time) 
Target density (space) 



ALTITUDE 



Engagement envelope 



SIZE 



Signatures 



DECOYS 



Decoys 



In the work on the subsurface threats there were like 
decisions tc be made which will be discussed to show some of 
the early discisions necessary for applicability or magni- 
tude considerations. 

At the stage just reached in the listing of important 
"air threat elements", the applicable "subsurface threat 
elements" were assumed as follows: 



Subsurface Threat Elements 



SPEED 



RANGE 
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SIGNATURES 



Radiated noise 



Acoustic cross section 



DECOYS 

In comparison to the air threat development at the same 
stage, some significant differences are apparent and should 
be explained. There is no subsurface counterpart to either 
altitude or density. In the case of depth (subsurface anal- 
ogy to air altitude) detection or destruction of subsurface 
threats was assumed to not be affected, to a first rrder 
level, by the depth of the target. This is a good example 
of the type of assumption which may be completely reasonable 
at a certain technology level (point in time) or for a spe- 
cific type of analysis, but which must be clearly and 
completely documented. Such documentation is mandatory so 
that, should the factors justifying or allowing such a sim- 
plification be altered for any reason, the model can be 
reconfigured to include the new and now driving consider- 
ation. In our example the omission of threat density for 
subsurface threats reflected current tactics of single ship 
action, vice World War II wolf pack type operations. Such a 
methodology even today may be highly suspect for mine field 
operations. Speed is included in the list because there is 
a wide range of relative target speeds. That is to say that 
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the weapons used to counter such threats are, typically 
working on the extremes of their capabilities. 

The remaining sections of the threat/environments devel- 
oped to equal degree as those just discussed were then; 

Surface Threat Elements 



SIZE 

RANGE 

SIGNATURES 

DECOYS 

Size was distinct from signature to account for 
survivability differences between vessels. Most existing 
algorithmns for survivability are based on overall length of 
the vessel in question. Note that speed is not included for 
surface threats. This is because the relative speed range 
of all possible surface threats is so small compared to the 
typical weapons used to counter it. 

Land Based Threat Element 
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Land based targets are included as a significant factor in 
payload requirements because the destruction of them is a current 
mission of some U.S. Navy surface vessels. They are, in effect, 
an "anti-threat". 



SIZE 



RANGE (TO) 

HARDENING (the degree of protection provided the site) 



Jamming Elements 

NOISE (electromagnetic energy density) 

CHAFF (physical interference with electromagnetic transmission by 
use of metal foil ribbons or pieces) 



Weather Elements 



VISIBILITY (unaided vision) 
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ELECTRICAL Disturbance (lightning, sunspots, etc) 
TEMPERATURE 

SEAS (height, period, direction) 

As might be expected, the next stage in the "top down" 
development process was to "brainstorm" the elements which 
directly and significantly effected each of the threat area 
elements. For example, it was necessary to determine what 
factors "defined" the signatures of a surface threat. A 
good initial approach was to identify such signatures by 
type transmission medium, i.e. air or water borne and to 
further break down these mediums by the types of energy 
transmitted within them: 



Air Borne 



Electromagnetic (energy emitted from on board equipment) 



Visual (reflectivity, color, roughness) 



Heat (infra red energy emitted) 



Noise (acoustic, air borne; used in detection only) 
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Radiation (sub-atomic particle air borne) 



Water Borne 

Radiated Noise (generated in the operation of the platform itself) 
Sensor Noise (acoustic, water borne, from sensors) 

Radiation (sub atomic particle, water borne) 

Wake (physical disturbance to normal ocean conditions) 

It is at this stage that we are truly making some 
progress toward our goal ; the identification of all major 
independent variables defining the performance of a surface 
combatant . 

This is an excellent place to point out one of the more 
basic errors made and the reasons for it. One of the air 
threat element identified was engagement envelope. This 
attempt to describe the threat in terms of the magnitude or 
means of the counter to that threat. In other words we were 
artifically defining both the threat and some of the parame- 
ters describing our counter to the threat by defining the 
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volume of space around out ship which we would "defend". 
The effect was to be describing the payload required in 
terms of desired or precieved performance as an input. This 
is not what the model was developed to accomplish. The idea 
was to input (or define) what must be countered by the com- 
bat systems payload and have the model, through a fully 
developed and broadly considered program provide appropriate 
means to actually "defeat" the inputed threat. Therefore, 
this approach was abandoned and the orignal premise of defi- 
nition by need, not means was begun for the air defense 
problem. The final list can be f oundstarting on page lAI of 
the Appendix. 

Another major omission of the threat/environment section 
as thus far developed was the omission of the difference 
between weapon and weapon platform as distinct but related 
factors. It was not sufficient to address, for instance, 
attacking missiles themselves. It is entirely possible and, 
in fact, most desirable to disrupt the air borne threat by 
"defeating" the weapons carrying platform prior to weapons 
release. We must, therefore, provide within our model, for 
the total of all elements which make up the weapon, the 
weapons carrier and finally the two together. This error of 
omission would be fundamental. 
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From this level of detail on, the major problem was of 
flow - cause and effect of each stage upon the other. The 
subsection of the example threat and environment menu which 
was fully developed was the "surface threat". A detail 
listing of all developed menus is included on the first page 
of the appendix. The next chapter will discuss this sub- 
section in greater detail. 
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CHAPTER 4 



DEVELOPMENT OF THE OBJECTIVE FUNCTION 

This chapter will offer the methodology for the develop- 
ment of the function used to assess the design. Each menu 
string in this model was designed to establish a hierarchy 
of parameters. That is within a given string, the elements 
defining a parameter are, hopefully, "downstream" of the 
things they are defining. However, at each menu level there 
are perhaps as many as 8 to 10 different parameters of equal 
status, all defining the next higher menu item. For 
example, returning to our example menu of chapter 2, we see 
that there are 4 possible weapons choices for the designer. 
How would the designer (model user) choose how many of each 
type weapon should he incorporate within his vessel? The 
ability to choose the proper or desired combinations of such 
things as fire power, speed, endurance, survivability or any 
of many other characteristics is essential. It must be 
remembered that, in general, these characteristics compete 
for vessel resources such as space, weight or manpower with- 
in a design. The remainder of this chapter will discuss two 
possible methods, for singular or combination use, for this 
important question, specif icially"; given that the model (or 
any model) has identified the pertinent independent vari- 
ables in naval ship design. How do we decide how much of 
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each is best? Or in other words; given the decision vari- 
ables; what is the objective function? 



The two techniques offered will be; 

A. Utility Theory 

B. Artifical Intelligence 

UTILITY THEORY 

We will demonstrate utility theory rather than define 
it. Things are "worth" more or less to an individual (or 
decision making group) depending upon the circumstances at 
the moment of evaluation. Take something as seemingly well 
established as the worth of a dollar. If you have $50.00 in 
your pocket, a dollar does not necessarily have too much 
value. If, however, you only need $.60 to ride the subway, 
but have no money at all, a dollar is something you could 
really appreciate One way of explaining this is to think 
of the utility of a dollar in each case. Another dollar, if 
you have fifty, is not too useful to your desire to go home. 
In the latter instance, that dollar has great utility if you 
want to avoid walking. 

Utility theory is one important consequence of the axioms 
of rational behavior. A person who accepts the axioms 
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.wishes to make his own decision processes consistent with 
them. To do so, he must always select decisions so as to 
maximize the expected utility of their outcome. The fact 
that it is the expected value of his utility which he must 
maximize is a consequence of the laws of logic themselves. 

We will initially limit ourselves to the case where a 
single quantitative attribute, x, is considered by the deci- 
sion maker to be an adequate description of the possible 
total consequences of his decision problem. Also, for sim- 
plicity, we first assume that the decision maker prefers 
larger values of x to smaller values. These restrictions 
(single numerical attribute, preference for the larger of 
two values of that attribute) will be removed later. 

Reference Lotteries and Indifference Probabilities 

Let x^ be the particular values of our single 
quantitative attribute, x, which apply to the consequences 
of the decision problem. Let x^ be some quantity as large 
or larger than the largest of the ' s and let x^ be a quan- 
tity as small or smaller than the smallest of the x^'s. To 
determine the utility of each x^ (and therefore of the con- 
seouence described by x ), we first establish the reference 
lottery of the form shown in Figure 4.1, such that the deci- 
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sion maker is indifferent between ownership of this lottery 
and obtaining the consequence of value x . This requires 
the measurement of p(x^), called the "indifference probabil- 
ity" for a consequence of value x^ . 

A utility U(Xj^) can then be assigned to each consequence 
such that 

U(x^) = kl + k2 p(x. ) 

where kl is any constant and k2 is any positive constant. 
For instance, if we set kl = 0 and k2 = 1, we may use the 
indifference probability itself as the measure of utility 
for any consequence.- 

Operationally, the procedure is not so useful, because it 
is difficult to assess the p(x^)’s. A decision maker finds 
it hard to distinguish between probabilities like 0.13 and 
0.17, for example, since one does not have a intuitive feel- 
ing for many probabilities other than 0.5. In the next sec- 
tion, we demonstrate a method for obtaining the utility of 
consequences without requiring the direct assessment of 
probabilities. 



A technique for Utility Assessment 
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Our basic concept is to assess the utilities of a few 
consequences and plot these on a graph with U(x) as the 
ordinate and x as the abscissa. We may arbitrarily assign 
utilities to two consequences for reference. Let us set 



u(xl) = 1 
and 

u(xO) = 0 

where xl must be preferred to xO. (This normalization is 
equivalent to specifying the values of kl and k2). Then we 
take the lottery in Figure 4.2 and find the value of x, call 
it X.5, for which the decision maker is indifferent to the 
lottery. The utility assigned to x.5 must equal the 
expected utility of the lottery so 

U{x.5) = 0.5U(xl) + 0.5 U(x0) = 0.5 . 

This gives us a third point on the utility graph in Figure 
4.3. Our technique allows us to obtain the utility of a 
third consequence x.5 relative to the utilities of xl and xO 
which were set to establish the origin and unit of measure 
of U(x). In obtaining x.5, we were able to keep all the 
probabilities encountered equal to 0.5. 
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This 



The obvious question is "how does one get x.5?" 
requires an interactive procedure, where the decision maker 
must state his preference between the specified lottery and 
a consequence. For instance, we would choose an amount x 

Q. 

and ask whether the decision maker would prefer obtaining x^ 

for certain or particiating in the lottery shown in Figure 

4.4. Regardless of which is preferred, we should be able to 

identify whether x should be increased or decreased to find 

a 

the amount x.5 such that the decision maker is indifferent 
between it and the lottery. For example, it might be obvi- 
ous that x.5 > x^. Then when a second consequence Xj^ is 

compared to the lottery, we may learn x.5 > Xj^ . Such infor- 
mation will bound the true value of x.5. If one continues 
in the manner, the value of x.5 will be found. 

An Example 

Let us illustrate some of these ideas with an example. 
Suppose we wish to assess your utility for all monetary con- 
sequences between zero and one thousand dollars. You can 
think of these values as possible changes in your net 
assets.' Since you would probably agree that $1000 is pre- 
ferred to $0, we can arbitrarily set the origin and unit of 
U(x), where x is a particular change in assets, by U(0) = 0, 
U(IOOO) = 10. Our next step is to determine the amount of 



43 



assets for sure which you feel is the least amount for which 
you would agree to sell the lottery shown in Figure 4.5. 
That is, we want your certainty monetary equivalent for this 
lottery. Suppose you decide it is $400. Then the utility 
which is assigned to $400 must equal the expected utility of 
the lottery, since they are indifferent and expected utility 
is our measure of preference. Hence, U(400) = 0.5 U(IOOO) + 
0.5 U(0) =5.0. We continue the assessment of your utility 
function. Let us attempt to find your certainty equivalent 
for the lottery shown in Figure 4.6. If this amount is 
$180, then the utility assigned to $180 must equal the 
expected utility of the lottery. So U(180) = 0.5 U(400) + 
0.5 u(0) = 2.5. Next we assess your certainty monetary 
equivalent (CME) for the lottery shown in Figure 4.7. Sup- 
pose your response is $650. We have: U(650) = 0.5 U(IOOO) 
+ 0.5 U(400) = 7.5. The idea should be clear by now. Let 
us plot a graph of U(x). From the last five equations we 
have five points on that graph. The curve in Figure 4.8 is 
drawn through those points and represents your utility func- 
tion for any increase in net assets from 0 to 1000 dollars. 
From the curve, we can see, for example, that the utility of 
$700 is 8. That is, U(700) = 8. Similarly U(500) = 6.3 and 
U(200) = 3.0. 
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Some Characteristics of Utility Functions 



There are many curves which we could have drawn through 
the assessed points in Figure 4.8. For instance, we could 
have chosen to use linear segments to connect adjacent 
points, to use regression analysis to find the best fit 
quadratic curve, or to "wiggle" any curve with ups and downs 
through the given points. In this section, the problems of 
choosing appropriately shaped curves is addressed. 



Rather than just evaluate some points and smooth in a 
curve, it seems reasonable to first try to obtain the gener- 
al shape of the utility function. This structure of the 
utility function can be specified by ascertaining whether or 
not the decison maker’s preferences satisfy certain 
criteria. Each of these criteria puts a restriction on the 
form of the utility function. A useful technique is to 
determine the general shape of the decision maker's utility 
function by obtaining a qualita' ive expression of his pref- 
erences, and then to choose a particular utility function 
satisfying the general shape requirements which is also con- 
sistent with a few carefully assessed values of U(x). 



The Art of Assessing Utility Functions 
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Assessing utility functions is perhaps more of an art 
than it is a science. The success one has in such attempts 
is closely linked with the analyst's ability to communicate 
with the decision maker — to indicate the importance of 
this process, to enlist his support, and to make him feel 
comfortable with the assessment procedure. 

For discussion purposes, the assessment procedure might 
be divided into five steps: 

1. Preliminaries to actual assessment. 

2. Specifying the relevant qualitative characteristics. 

3. Specifying quantitative restrictions 

4. Choosing a utility function 

5. Checking for consistency. 

Preliminaries to Actual Assessment 

Before beinning the assessment of a utility function, the 
concept of decision analysis should be discussed with the 
decision maker. Thus, he should realize the purpose in 
assessing his preferences and hopefully be sufficiently 
motivated to think hard about his feelings for the various 
consequences. It should be made clear to the decision maker 
that the preferences of interest are his -- that they repre- 
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and that there are no 
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Specifying the Relevant Qualitative Characteristics 

The qualitative characteristics we are interested in are 
monotonicity and attitudes toward risk. To ascertain ’ wheth- 
er a monotonicity condition is appropriate is quite simple. 
One asks the decision maker which is preferred between xl 
and x2, where x2 > xl. Probably you, the assessor, would 
expect a certain answer to the question based on your own 
understanding of the consequences. If x2 is prefered, you 
would tend to think preferences are monoton ically increasing 
in attribute x. You would then just ask whether more of the 
attribute is always preferred to less of it. 
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To check for risk properties, you might divide the range 

of the attribute as illustrated in Figure 4.9. We would ask 

the decision maker whether he prefers the lottery in Figure 

4.10 or its expected value x for certain. Note that this 

c 

lottery covers the complete range of the attribute for the 
problem at hand. If x^ is preferred, we are inclined to 
think the decision maker is risk averse; if the lottery is 
preferred, he is likely risk prone. To check subranges, we 
ask for preference between the lottery in Figure 4.11 and 
its expected value, Xj^. We also ask the dec ision' maker ' s 
preference between the lottery in Figure 4.12 and its 
expected value, x^ . If the certain amounts are preferred 
here, as well as with the first lottery, we will probably 
find it reasonable to assume the decision maker is risk 
averse . 

If sometimes the lottery is preferred and sometimes the 
sure consequence is preferred, we would need to check fur- 
ther to see whether the decision maker was risk prone in 
some region of x and risk averse in another, or whether he 
had made an error in his initial responses. 



Specifying Quantitative Restrictions 



48 



To specify quantitative restrictions, we perform the 
assessment of some points on the decison maker's utility 
curve. We have already shown how to do this by assessing 
the certainty equivalents of a few lotteries. There are a 
couple of pragmatic points to keep in mind, however. First, 
the consequences used in the questioning must be meaningful 
to the decision maker. Secondly, the spread of consequences 
in 0.5 - 0.5 lotteries must be large enough to be meaning- 
fully different. That is, if we are talking about a utility 
function for $0 to $1000, it is not very meaningful to ask 
questions about the certainty equivalent of a lottery such 
as the one shown in Figure 4.13 since there would be little 
perceived difference between the $500, $520 and the certain- 
ty equivalent. 

Choosing a Utility Function 

Once the qualitative characteristics have been specified, 
we will be able to select a parametric class of utility 
functions which satisfies these properties. Let us desig- 
nate this as U(x/X) where X represents the parameters. We 
would expect at most three parameters to allow a suitable 
representation of any utility function. 
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Then if x3 



is the certainty equivalent for the lottery 
shown in Figure 4.14 we know U(x3/A) = 0.5 U(xl/X) = 0.5 
U(x2/ X ) which gives us one equation with the number of 
unknowns equal to the number of parameters. Using such cer- 
tainty equivalents, we obtain the same number of equations 
as parameters, and then solve the set for the parameters. 
This will provide us with a utility function. 



Checking for Consistency 



There are many different consistency checks which can be 
used to detect "errors" in the decision maker's utility 
function. By an error, we mean the utility function which 
we have assessed for him does not adequately represent his 
true preferences. There are a variety of ways to ascertain 
whether certain qualitative characteristics, such as risk 
aversion, hold for a particular utility function. One way 
can be used for a check on the results of another, etc. One 
generally useful check involves asking the decision maker 
his preference between any lottery and any consequence, or 
between two lotteries. In both cases, the expected utility 
of the preferred situation as calculated from his utility 
function must be greater in order to be consistent. Whenev- 
er the analyst feels uncomfortable about any aspect of the 
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decision maker's 
check this aspect 



utility function, it would be useful to 
and make any appropriate adjustments. 
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MULTI -ATTRIBUTE UTILITY 



Ships, like other large systems, have many attributes In 
general, the value of any design is seen to be some U(xl, 
x2,...xn), where xl is a single attribute. Our next goal 
will be to assess and measure U(x), so that alternative 
design with different x, can be ranked analytically. This 
ranking should be somehow responsive to both the underlying 
attitudes toward varying amounts of each attribute and the 
relative importance of different attributes. 

When many attributes are considered in project 

evaluation, it is commonly assumed that: 

U(x) = Ui[x(i)3 = 

i i 

That is, utility is additive and linear. 

In particular, traditional benefit-cost analyses simply 
assign a constant dollar value (a^ ) per unit of each 
non-monetary attribute, and then add up the resultant bene- 
fits. Individual preferences are summed up by converting 
all desires into a "willingness to pay" for a good or ser- 
vice, a process that in general favors the wishes of most 
well-to-do of the decision makers. The consequences of this 
fact are significant to the national naval budget process. 
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The most interesting of cases of single~attribute utili- 
ty functions are distinctly non-linear, so the simplifi- 
cation of (Xj^ ) to (Xj_) is not appropriate. Given 

non-linear utilities, however, it is then permissible to 
derive U(x) as 

U(x) = ^ \ U(x^) 
i 

Certain sophisticated benefit-cost analyses, for example, 
use nonlinear demand functions, and then add up the benefits 
derived from each attribute. 

However, consider the following example: 

xl = endurance range 
x2 = maximum speed 



Obviously, the importance of each of these factors will 
not be independent of the other, at least to many observers. 
For example, the significance of maximum speed is very much 
damaged by endurance. Therefore, the difference between the 
utility of low speed and that of a very high speed is great- 
er if the endurance is higher. 
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Note that Ab > La., which can not be duplicated by an addi- 
tive model, in which U( 0 ,X 2 ), X 2 's contribution to utility, 
may move up and down as X 2 changes, but, A , x^' s maximum con- 
tribution to utility, must be constant, regardless of the 
value of x^. Note that U(xj,) is not depicted as being line- 
ar, either. 

Since we have discarded the linear and additive assump- 
tions for multi-attribute utility functions, you may wonder 
why we do not just estimate utility directly, as we did for 
single-attribute utilities: choose the endpoints (U=0, U=l) 
use a 50/50 lottery to determine the utility midpoint 
(U=.5), repeat to find the quartiles (U=.25, U=.75), and 
draw a smooth line through the points. In three questions, 
we determine five points on the utility function, and with 
some restrictions to ensure the curve is monotonic to assure 
a smooth function, we can derive a reasonable approxim.ation 
of the shape of that function. 
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However,' when we attempt to extend this methodology to 
multi-atttibute situations, we run into the famed Curse of 
Dimensionality. In two dimensions, we would presumable want 
to know the utility of at least five points on each axis and 
their intersections in the planes; Now there are 25 points, 
of which only two are fixed by convention (U=0, U=l). If 
the determination of each point requires one question, 23 
questions are necessary to approximate the surface. Three 
attributes require 123 questions, four demand 623, and five 
necessitate 3123 questions. Decent results would be unlike- 
ly beyond 2 dimensions: even the most cooperative decision 
maker will be hard pressed to answer more than a hundred 
lottery questions thoughtfully. Furthermore, under the pro- 
posed assessment technique, the maximum possible distance 
between a point of interest in the attribute space and the 
nearest point for which the utility has been assessed is 
proportional to the square root of the number of attributes: 
assessment becomes both more difficult and less accurate as 
dimensionality increases. 

Theoretically two approaches are possible to solve the 
multi-attribute problem. As we demonstrated above, the 
first is an exhaustive comparison of alternatives; the large 
number of assessments means this method has little or no 
practical merit. The second approach employs behavioral 
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assumptions to approximate the exact utility function; the 
decision analyst uses these behavioral assumptions together 



analytically . 

This second approach is further divided into two schools 
of thought. The Harvard-MIT school restricts the utility 
function directly through "independence" assumptions about 
the preference between subsets of the attributes. The 
Stanford school separates the utility assessment process 
into two stages; first, the ordering of trade-offs under 
certainty among the attributes and, second, the assessment 
of a risk preference function on one "numeraire", or rank 
order, for the deterministic ordering derived in the previ- 
ous stage. The basic research for that work is contained in 
the Ph.D theses of D. Boyd and Thomas Green at Stanford. 
The remainder of this discussion provides an overview of the 
Harvard-MIT approach. 

The Karvard-MIT method simplifies the problem but not as 
severely as the linear additive model first discussed. The 
utility function , however, is still decomposed: 



with a few assessments to model the preferences 




60 



We still retain the individual U,(x. )f each obtained by ask- 
ing 3 questions per rather than approximating them with a 
linear function. Furthermore we will find some more sophis- 
ticated way of combining the U^(x^) than simply adding them 
up. Specifically we will assume 

preferential independence 
utility independence 

Preferential independence is an ordinal quality 
the order of preferences (involving x^ and x^ is independ- 
ent of other attributes , . . . crudely, the choice 

between two attributes is the same regardless of the level 
of other variables. Specifically, if one set of attribute 
levels (x^ , x^ ) is preferred to another set x^ , x^ ) when 

the other attributes have values (x^, x^ , . . . ) , then (x^ 

Id t) 

, x^ ) is still preferred to x° , x^ ), even though the oth- 
er attributes take on different values (x^ , x^ , . . . x^ 

3 4 n 

) . Symbolically : 



xp 1 


(X3. 


• -x„) > (xj. x^) ! 


1 (X3. . 




xp 1 




■ -x^) > CxJ, x^) 1 


1 (x’- . 





Here is an example which illustrates the meaning of prefer- 
ence • i ndependence : 
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CASE B 



CASE A 

RAXIMUM SPEED CP^W COMFORT 





= RESOURCES NOT 


USED 




= NOISE LEVEL 


^2 


= RANEU\rERABILI' 


TY IMPROVEMENT 




= VIBRATION 


LEVEL 




= REACTION TIME 


IMPROVEMENT 




= LIGHTING 


LEVEL 


^4 


= TONS OF STEEL 


AVAILABLE 




= CROWDING 


INDEX 



IF WE KNOW 



a =10,000 a ' 

^ > 


= 6,000 


b = 70db b' = 60db 


a^ = 10% a’ 


= 20% 


b, = lOdb b: = 30db 

2 2 



GIVEN THAT 



a^ = 15% 


bs = 


a, = 500,000 
4 


b, = 53 
4 



THEN GIVEN 



a = 50% 

3 

a = 100,000 



b = 75 

3 

b = 27 

4 



or any other 
such combination 



PREFERENCE INDEPENDENCE IMPLIES THAT 
IT STILL HOLDS THAT 



= 10,000 a’ = 6,000 

> ^ 




= 70db b’ 

> ^ 


= 60db 


= 10% a^ = 20% 




= lOdb b^ 


= 30db 



> : The ordered pair is preferred 
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On the other hand, diet problems (among others) readily 
present counter examples to preference independence. 



While preferential independence does 
case, it does show up in many practical 
where it is not true of one statement 
problem can frequently be re-formulated 
ables that are preferential independent. 



not hold in every 
situations. Even 
of a problem, the 
in terms of vari- 



The second and much tougher assumption, utility independ- 
ence, specifies that the shape of U(x) as x^. changes (with 
( i j ) held constant) is independent of the level of the Xj 
. With respect to design of a ship, for example, if the 
utility curve looks like: 




then utility independence allows 




the function to look like: 
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3 




if safety is poor, depending on U{Pmin, Safety Poor) and 
U{Pmax, Safety Poor): in each case, half of the utility 
change takes place in the first third of the profit range. 
But it can not look like: 




or 




Our U(Profit) can be expressed in a single graph as: 




Once and are determined (as a function of safety), 
the utility curve for profit is fully defined. If we know 
the utility of some amount of profit Pq , given safety level 
1, what does that tell us about U(Pq), given safety level 2? 
Our utility independence assumption requires that U(PqS), 
always be some fixed proportion of the distance from to 
(S). 
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Therefore 





U(P,S) - U^(S) 

— — = Constant 

U*(S) - U^(S) 


so letting S 


= 1 and S = 2 , 


U(P„,2) = 


U(P-,1) - U^(l) • (U^(2) - 

' ^ ^ 

U*(l) - U^(l) 


or 

U(Pq ,2) 


= U*{2) - • U*(l) + • U(P„ ,1) 


where 


_ “*) - 

- D*(l) 


or 


= "l,2 + ^,2 • 


where 


^1,2 = "*<2) - b^_^ • U*(l) 



Now a and b are only functions of safety so, 

± f ^ X / Z 



Therefore , 


U(P„,2) = + b^^^ • U(P„ ,2) 

U(P, 2) = a j 2 + 2 U(I’-l) 
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for all ?, sirr>ply a linear transformation of U(P,1). 

Equation (A) allows us to prove a very important point: 
utility ("shape”) independence implies that preference 
between lotteries in one attribute is not affected by the 
level of other attributes. 

For example, given: 



we know 

U(A,1) =p-U(B,l) + (1-p) U (C,l) 

to show that 

U(A,2) = p-U(B,2) + (l-p)*U(C,2) 

that is, the indifference between A and the lottery is main- 
tained when safety changes, we simply note (dropping the 
subscripts ) : 

U(A,2) =a + b • U(A,1) = a [p + (1-p)] + b [p -U (B, 1) + (l-p)-U (C,l)] 

= p[a+b- U(B,l]+ (1-p) [a + b • U(C,l] 

= p • U(B,2) + (1-p) ' U (C, 2) 

And that's why it's called utility independence! 




Profits A,B, or C 
Safety = 1.0 
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We have discussed preferential independence two attri- 
butes with respect to all other attributes, and utility 
independence of one attribute with respect to all others. 
The independence concepts can also be defined in terms of 
other numbers of attributes -- but such properties need not 
be demonstrated in order for the following technique to be 
justified. 
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'ill*' 



Artificial Intelligence 



The second technique offered will be called broadly 
termed artificial intelligence. Although it is certainly 
true that a computer can not think, it is foolish to over- 
look or ignore the computer's ability to recall out the 
actions, good and poor, taken by others. In simplest terms 
decision maker acts, not only on his own opinions, but upon 
the preceived or known actions of thers in similar circum- 
stances. The field of "artificial intelligence" is little 
more, in this least sophisticated form, than pathed actions 
made by the computer based on a statistical preference of 
previous human decision makers. Although this research will 
not attempt to develop the scientific basis for artificial 
intelligence aided decision making, it will stress one opin- 
ion . 



To use this discipline a foundation of previous decisions 
in similar circumstances is required. Since individual lev- 
el decisions are being made in existing combat simulation 
and ship synthesis models, the retention and cataloging of 
them should be started. 



It is believed that both utility theory and artificial 
intelligence might prove significant aids to our unresolved. 



V 



but pivotal problem. The ultimate decision of which 
quanitates and in what proportions should be included in a 
specific design. The purpose of each is the same. Show the 
decision maker how to include his preferences within a deci- 
sion toward a consistently defined problem. It is this need 
for a common definition of the problem which must be solved. 
It is offered that we have multi attribute utility theory to 
address the number of elements and, perhaps, artificial 
intelligence to assist in the problem of multi decision mak- 
ers. The two techniques may prove ultimately complementary 
to the resolution of the appropriate ship design objective 
function . 
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CHAPTER 5 



THE ASSET SHIP SYNTHESIS MODEL 



A method must be found to translate the hardware payload 
and the conceptual platform into first, comparable terms and 
second, into a first approximation of a ship. In this 
project the following characteristics for this translation 
were considered desirable. 



1. 


Executable within DEX 


software . 


2. 


State of the art 


model 




3. 


Interactive 






4. 


Able to take 
framework of the 


full 

model 


advantage of this models the 
we have proposed. 



The most efficient method of achieving the second of 
these objectives was to find an existing ship synthesis mod- 
el which was developed to to incorporate many if not all, of 
the aspects we identified in previous chapters as essential, 
with the limitations of other models discussed in chapter 1. 
Independently to this research, the project team was intro- 
duced to the directors research team at the David Taylor 
Model Basin in Carderock, Md. This group was actively 
involved in the development of a ship synthesis model 
intended to provide for the analysis of the effect of tech- 
nological changes upon a ship design at the feasibility 



70 



stage of the design process. The "Carderock" model is 
excellent for the purposes of our effort. This is because 
it can be initiated by the fewest and most elementary of 
descriptive parameters. In addition the Carderock model 
allows for development/modification of all included concepts 
in extensive depth. Because of the significant efficiencies 
to be gained by using an existing model in our project, and 
DEXs' ability to accomodate existing analysis code with min- 
imum modification it was decided to develop the combat 
effectiveness model with the explicit intention of using 
ASSET as the vessel synthesis technique. 

The Carderock model is called Advanced Surface Ship Eval- 
uation Tool (ASSET) and is an interactive computer program 
for use in preliminary evaluation of frigate, destroyer, and 
cruiser-type ships. It will ultimately encompass virtually 
all major technologies that are relevant to the design of 
such ships, including hullform sizing, hydrodynamics, pro- 
pulsion, structures, weights, hydrostatics, cost, manning, 
space requirements and survivability. The program features 
design synthesis capability, options, including interactive 
graphics and use of either English or metric units. ASSET 
is primarily intended as an interactive tool for providing 
timely resuts to engineering queries. 
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ASSET was designed to avoid the pitfalls typical of pro- 
grams of similar scope, such as extreme difficulty of use, 
poor responsiveness to engineering queries, and inadequate 
technical depth in the multidisplined environment. The 
ASSET engineering modules for ship design are manipulated by 
the user via a small yet powerful set of commands. ASSET 
was designed to execute interactively via a teleterminal to 
provide desk-top convenience while avoiding delays inherient 
in batch (card) oriented systems. Finally, the ASSET engi- 
neering tools represent most of the major technologies that 
are relevant to destroyer-type ships. ASSET consequently 
allows an increase in engineering productivity during the 
ship design cycle by allowing the user to apply the ASSET 
engineering tools in an easily-used, responsive, yet techni- 
cally sophisticated environment. 

Use of the ASSET engineering system closely parallels the 
classical process of ship design. The design team begins 
with a set of mission requirements that the proposed ship is 
to accomplish. Existing design data and computational pro- 
cedures are employed in an iterative sequence to derive a 
ship design, as exemplified by the design spiral. ASSET'S 
value is in the automation of many of the manual processes 
performed in the iterative design process. Instead of manu- 
al search through lengthy residuary resistance coefficients, 
ASSET performs the search. Instead of manual construction 



72 



of a plot of hydrostatic righting are versus heel angle, 
ASSET draws the plot. Instead of manual storage of design 
data in notebooks, ASSET stores the data on computer disk 
files, from where it may be easily recalled and reviewed. 

Although many of the precesses involved in the design of 
a ship are automated by ASSET, the program leaves the crit- 
ical engineering decisions to the designer. ASSET makes no 
attempt to decide whether to employ waterjet or propeller 
propulsion, whether to use Newton-Radar or Wageningen-B 
propeller curves, or whether to use a three or four bladed 
propeller. ASSET makes no significant design decisions 
whatsoever. The program employs selected algorithms to per- 
form selected calculations. The designer retains essential 
control of the program. 

PROGRAM STRUCTURE 

PROGRAM CONCEPTUAL ORGANIZATION The system is composed 
of five principle elements: the designer, an executive pro- 
gram, a series of computational programs, a ship design 
undergoing generation or analysis (called "current model"), 
and a data bank. 

DESIGNER The designer is the controlling element of the 
ASSET system. Through a simply command language, the 
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designer directs execution of, or interaction between, the 
remaining system elements. Although capable of batch (via 
cards) execution, the ASSET system was designed as an inter- 
active tool for ship engineering. Consequently, the design- 
er typically utilizes ASSET by means of a teleterminal where 
commands may be entered and results of those commands imme- 
diately reviewed. Delays are thereby minimized. 

EXECUTIVE PROGRAM The executive program is the ASSET 
system element that interprets each user command and there- 
after performs each task that is required to accomplish the 
user instructions. The executive program is also the lone 
system element that can directly interact with each of the 
other system elements. Performance of any given user com- 
mand generally involves the remaining three system elements. 

CURRENT MODEL The current model element of the ASSET 
system is the temporal collection of data that represents 
the one ship design under generation or undergoing analysis. 
All program computations use current model data only. The 
current model is temporal because it exists only during exe- 
cution of the program. To become permanent, current model 
data must be transferred to a permanent storage device. 

DATA BANK A data bank has been incorporated as an ele- 
ment of the ASSET system for the purpose of permanent 
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retention of ship data. Entire current models or pieces of 
a current model may be stored in the data bank under a name 
selectable by the user. During an ASSET session, ship data 
may be transfered from the data bank to the current model or 
from the current model to the data bank. 

The executive program, the current model, and the data 
bank can also be employed to create entirely new ships in 
the current model by recall from the data bank of pieces of 
data from different ships. For example, one can transfer 
ship data corresponding to the propulsion system of Ship A 
from the data bank to the current model and then transfer 
hull offset for Ship B from the data bank to the current 
model. The current model would thereby contain a vessel of 
Ship A type propulsion system but Ship B type hull. 

COMPUTATIONAL PROGRAMS 

The calculative function of ASSET list performed by the 
element that consists of eleven computational programs. 
Each program represents a distinct engineering technology 
that can be applied to the design and analysis of ships. 
Through a simple command to the executive program, it is 
given to the computational program. Following termination 
of the computational program, output data, selectable by 
menu, are displayed to the designer. Certain computational 
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programs also add to, or modify, the current model *as part 
of the ship design-generation process. 

COMPUTATIONAL PROGRAM TYPES Three types of computa- 
tional programs within ASSET: initialization, synthesis, 
and analysis. The description of the programs within each 
type is given below. 

The initialization section of ASSET consists of a single 
program. It utilizes simple empirical methods to calculate 
a variety of ship data. As its name implies, a primary 
function of the initialization program is to provide an ini- 
tial starting point for a new design under development with 
ASSET. A secondary use of the initialization program is in 
performance of high-level, parametric trade-off studies. 

Six synthesis-type computational programs exist within 
ASSET. Each program is concerned with a single technolog- 
ical area of the ship design. In contrast to the initial- 
ization program, each synthesis program utilizes rigorous 
analytical techniques in computation of ship data. 

The third type of computational program is called analy- 
sis, of which there are four. Like the synthesis programs, 
rigourous analytical techniques are employed. The principal 
difference between synthesis programs and analysis programs 
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is that synthesis programs modify the current model. Analy- 
sis programs do not modify the current model, only provide 
additional information about it. Also unlike analysis pro- 
grams, synthesis programs can be employed in an iterative 
loop to converge on a ship design. The process, known as 
design synthesis, is simply an automated traverse of a 
design spiral from the mission requirements to the converged 
upon ship design. 

COMPUTATIONAL PROGRAM FUNCTIONAL DESCRIPTIONS 

The function performed by each ASSET computational pro- 
gram is described in the following section. 

INITIALIZATION 

This program is normally the first program to be exer- 
cised after assembling a new ship in the current model. 
Data is thoroughly checked for completeness and if no fatal 
errors exist within the data, a mini-design synthesis proc- 
ess is initiated that contains geometric, hydrodynamic, pro- 
pulsion, performance, and weight calculation capability. 
Simple empirical methods are used throughout. The calcu- 
lation sequence used by this program is as follows: 
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1 . 



Input data are checked. 

2. Ship weight is estimated. 

3. Hull is resized, if requested. 

4. Auxiliary and electrical systems are sized. 

5. Hullborne ship drag force is calculated. 

6. Hullborne propulsion system is sized. 

7. Ship range or fuel weight is calculated 

8. Ship weight is recalculated. 

9. If the ship weight calculated in step 8 does not equal 
the weight as previously calculated, the mini-synthesis 
cycle is repeated from step 3 until weight convergence 
occurs . 



HULL GEOMETRY 

The hull geometry program defines girder, and deck 
locations, and also defines superstructure and hull 
geometry. Hull offsets in the current model are scaled and 
warped to define a new fullform that meets requested phys- 
ical characteristics. This program includes portions of the 
Navy program "Hullform Derived from Parent." 

This module calculates scantling data for the ship ele- 
ments defined in the current model. The calculations are 
based on pressure loading data which are either calculated 
by the program or input by the designer. Scantlings are 
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determined at three longitudinal locations for the hull bot- 
tom, hull sides, and weather deck. Additional scantling 
data are calculated for lower decks, bulkheads, frames, 
girders, beams, and stiffeners. 

HULLBORNE HYDRODYNAMI CS 

The hullborne hydrodynamics program calculates ship drag 
during hullborne operation. Either planing hull or Taylor 
Standard Series drag-type calculations may be performed. 

HULLBORNE PROPULSION 

The module performs sizing calculations for either a 
waterjet or propeller propulsion system. The 

water jet-propulsion system section of this program calcu- 
lates engine power requirements, water-duct losses, pump 
size, and operating data based on given drag, duct, and pump 
type data. The propeller size, and propeller operating data 
based on given drag, gearbox, and propeller characteristic 
data . 

FUEL/RANGE 

Range performance is calculated by this program in either 
of two ways. The weight of fuel required to achieve a spec- 
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ified hullborne range is calculated or the range which may 
be achieved by a given ship is calculated. The calculation 
mode is specified by the designer. Fuel requirements for 
auxiliary and electric plants are also considered. 



WEIGHT 



The weight program calculates a detailed weight breakdown 
for the ship. The weight statement follows the Navy Ship 

Work Breakdown Structure, SWBS.(see OPNAV Inst 9100.2b, 
1978) 

PERFORMANCE 

The performance program calculates the performance char- 
acteristics of ship designs that have been generated via the 
design synthesis process. Whereas design-synthesis perform- 
ance calculations assume calm water and a clean ship, the 
performance program considers fouling effects of marine 
organisms, degradation of machinery with time, and sea state 
operation . 

COST 

The cost program estimates ship costs for the purpose of 
design tradeoffs and comparative evaluation. Both unit pro- 
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duction costs 'and life cycle costs are addressed. Simple 
empirical relationships based primarily on the Navy SWBS are 
used to estimate unit costs. Life cycle costs are estimated 
utilizing a variety of data. 

GEOMETRY DISPLAY 

The geometry module produces plots of ship geometry. 
Hull lines, bulkheads, decks, and superstructure can quickly 
and easily be assessed for correctness by the designer. 

DESIGN SYNTHESIS 

The design synthesis process is another step employed in 
the manual process of ship design that has bee’n incorporated 
into ASSET. After establishment of mission requirements, 
the designer typically generates an initial design to serve 
as a starting point. This initial design may be a previous- 
ly established design of similar function or an entirely new 
concept. Unfortunately, the initial design is seldom satis- 
factory. Minor or gross modifications must be performed. 
For example, additional cargo volume may be needed. The 
designer may elect to expand the hullform to satisfy this 
need. But expanding the hullform changes ship resistance, 
which impacts required propulsive power, which may demand a 
new power plant, which may change the amount of fuel carried 
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to achieve a desired range. The modified hull, propulsion 
plant, and available fuel impact the total weight of the 
ship. The initial estimate of ship displacement for which 
resistance calculations were previously performed may 
require revision, and new resistance calculations may need 
to be performed. The design spiral goes on and on, hopeful- 
ly toward a converged design. 

The key to operation of the design synthesis process is 
the ability of each synthesis module to modify the current 
model. Critical ship data in the cuerrent model such as 
hull lines, superstructure characteristics, hullborne drag, 
hullborne propulsion data, fuel/range data, and ship weights 
are modified during the synthesis process, each by the 
appropriate computational program. Convergence of a ship 
design occurs when two passes through the synthesis loop 
produce virtually indentical designs. 

This project has been designed to implement ASSET through 
the techniques of the DEX. Initial investigation with the 
ASSET development team has confirmed the opinion of the team 
that initiation of ASSET through DEX will be relatively 
straightforward. It is expected that the initialization 
section of ASSET can be called into this model, through DEX, 
in as few as 4 menus consisting of approximately 15-20 
design parameters. 
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CHAPTER 6 



COMBAT EFFECTIVENESS 

This section is the most important of the entire project. 
The development of this section focused upon the following 
three considerations. 

Completeness 

Accountability 

Applicability 

Completeness 

The content of this section is as follows: A. the situ- 
ation is defined, including; the composition of forces on 
both sides (this information is obtained from the current or 
a redefined situation obtained from section la "Threats and 
Environment" B. The operation or employment of each vessel 
is specified. In this sub section, the opposing forces are 
further defined as modeled at the moment at which an esti- 
mate of combat effectiveness is desired. The sub section 
will prompt the user to specify the status of each major 
parameter of the opposing forces. It is intended that this 
potentially laborious task be eased by having this specifi- 
cation done by default. That is, that items not 
high-lighted by the user are assumed to be operational and 
in operation to the extent of availability and performance 



83 



previously given. C. The definition of combat effectiveness 
is assumed to be an unspecified combination of the amount of 
"damage" inflicted upon the enemy and the amount of surviv- 
ing capabilities of the designed vessel after the action. 
Each of these major combat effectiveness parameter paths is 
developed to the degree required by the other two consider- 
ations of this section; accountability and applicability. 
Note that we are, again, avoiding answering how much each of 
these paths might contribute to an overall definition of 
"effectiveness". Extensive amount of discussion with opera- 
tional and design authorities indicated that such an 
evaluation is a function of 

How the totality of overall conflict is perceived 

The perceived strength of enemy in general area {poten- 
tial immediate opponets) 

Perceived relative strength trends of the opposing 
forces. 

Accountability 

In various areas of this model, extensive menu strings are 
taken, intact, from one section to be used in a higher level 
section. As such, these strings must be correct and concise 
as possible for all sections in which they are used. They 
should provide the difficult balance between what is neces- 
sary to sufficiently specify the problem, and the desire to 
limit the total number of possible decision points to sim- 
plify the execution of the model. The method used to 
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accomplish this trade-off was "comparision and reduction" 
from a higher (earlier) section to the section under devel- 
opment. For example, in choosing the surviving capabilities 
to be included in the "Combat Effectiveness" section (7), 
the section describing the payload (3) and the section list- 
ing the platform characteristics (5) were compared. From 
the gross list formed by the total of the two sections, a 
shorter list was formed by eliminating redundant or overlap- 
ping elements. As discussed in chapter 2, this reduction 
was accomplished by weighing the opinions of several 
war-gar Ing experts (most notably, John Corsey of the U S 
Naval War College) and personal opinions gained by the 
author from specific literature reviews (see the bibliogra- 
phy section on "Professional Publications"). 

As might be concluded, this is a highly subjective proc- 
ess with all the attendant dangers of such a generally 
described process. Because of this, the validity and com- 
pleteness of this section should be the initial area con- 
firmed by any future researcher in this field. Within this 
section, the output or product of the entire project is the 
most sensitive to changes in format and construction of the 
individually included menu items. To aid in menu account- 
ability, a section menu to section menu listing for the 
section is given below. 
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COMBAT EFFECTIVENESS MENU 



THREAT MENU 



must be consistent with 



"threets neutrelized" 
{by type) 


"threet type" 


"threets demeged" 

(by type/emount/eree) 


"threet types" 



COMBAT EFFECTIVENESS MENU 


PAYLOAD MENU 


must be consistent 


with 


"self defense cepebilities" 


"peyloed; self-defense" 


"force defense cepebilities" 


"peyloed; force/eree defense" 


"offensive threet 


"peyloed; offensive threet 


neutrelizetion cepebilities 


neutrelizetion cepebilities" 



COMBAT EFFECTIVENESS PLATFORM CHARACTERISTICS 

must be consistent with 

"fleg CCC cepebilities" "fleg CCC cepebilities 
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Applicability 



This term is used to indicate the constant responsibility 
for each included menu item to be necessary. There is a 
conflict with this desire and the stated "design philosophy" 
precept concerning highest level development. Because of 
the desire to give precedence' to the design philosophy, 
there was been only first order efforts in the area of 
applicability in the model as a whole. In the Combat Effec- 
tiveness section the availability of experts and excellent 
references, allowed some significant "winnowing" of the sec- 
tion. In general, this section is designed around the 
* 

existing gaming algorithms as used in this country. Many 
elements which would be significant to the naval architect 
are not significant to the combat simulator because he sim- 
ply has no way to account for them. 

Operation of the Combat Effectiveness Section 

Once the user has defined the general situation from 
which he wishes to obtain an estimate of combat effective- 
ness, he is ready to exercise the sections computational 
areas. Because this area is designed to be the most innova- 
tive of the project, we will describe this translation. The 
sequence would proceed as follows: 
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PROBABILITY OF DETECTION 



DETECTION RANGE CALCULATION 



GRAPHIC TECHNIQUE 

(MAXIMUM SENSOR RANGE 30 nm) 

TYPE 1 

100 
80 
60 
40 
20 

0 ,, 

Onm lOnm 30 nm 

DISTANCE IN nm 
DETECTION RANGE THRESHOLD (67%) = 10 nm 




FIGURE CE-1 



1 . 



The setting of the conflict is established. As previ- 
ously discussed, this might include, weather, other 
units or any other factor which could affect the outcome 
of the engagement as modeled. 

2. The operating status of the units is defined. Here we 
specify the on/off status of the sensors, weapons or 
other equipments having a detectable signature. 

3. The relative position of the conflicting forces is set. 
There are several range possibilities, with attendant 
action possibilities including; 

Outside of sensor range (by sensor system) 

Inside sensor range, outside all weapons systems 
ranges 

Inside sensor range, inside weapon systems range ( 
by weapons system) 

Inside minimum weapons range (by weapons system) 

4. Action is joined at the range specified in step 3 



Once either unit is within the maximum dectection range 
of an operational sensor, the detection event must be 
resolved. The detection event can be looked at in two ways. 
The probability of detection at a given range, or the range 
at a given probability of detection. Since we need the 
range of an action to proceed to the next step in the model 
we will use the range at which the target is assumed to be 
detected by the sensor. The method used to find that range 
could take many forms. The most accurate might use histor- 
ical information from "similar" encounters. Another 
technique would be to use the design specifications of the 
equipment. The third method might be algor ithimic . This is 
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the technique we will use. In this algorithim, we will 
assume a linear "curve” describing the distribution of the 
probability of detection from the maximum design detection 
range to the minimum. See figure CE 1. This implies that 
the target is becoming more easily detected as an inverse, 
linear function of range. In addition, we will specify 
that, not withstanding the finite probability of a detection 
at any range less than system maximum, the target will be 
assumed detected only when the probability of detection 
reaches 67%. That is, in 67% of assumed cases the target 
was detected prior to this range. In the example on the 
next page, dectection will, therefore, always occur at lOnm. 
This assumption is not as artificial as it might appear, as 
most systems and systems operators do not, routinely, per- 
form to the systems "advertised" specifications. The actual 
percentage threshold range is arbitrary, of course. 
Although a more generous threshold detection range may be 
specified, it is not important to the technique. An example 
is developed in figure CE 1 in graphic form. 

Given that the detection has occured, the next opera- 
tional decision would be to join or decline action. If, in 
the model, the defined situation, (or the users override, 
see chapters page 30) specifies action the model proceeds as 
follows . 

Weapons Action 
89 



WEAPONS CIRCULAR ERROR OF PROBABILITY 
(in yds) 



CIRCULAR ERROR OF PROBABILITY (C.E.P.) 
CALCULATION 



GRAPHIC TECHNIQUE 




AT 10 nm C.E.P. = 500 yds 



f- 1 



FIGURE CE-2 



A weapons action is defined as the determination of the 
number of expected hits by a given weapon upon a given tar- 
get at a specified range. The calculation assumes that the 
system is operational and the target is within maximum weap- 
ons range. Of the many possible methods of such a determi- 
nation, this model will; 1. Define the length of the 
engagement. This will give the number of rounds fired based 
upon the systems firing rate (note that firing rates are not 
necessarily single valued). In our example, 1 minute firing 
with a firing rate of 30 rounds per minute gives 30 rounds 
fired. 2. Calculate the weapons "circular error 
probability" (CEP). This parameter measures the expected 
dispersion of warhead impact points as a function of range. 
In simple terms it describes the circle within which 50% of 
the rounds fired would be expected to land. For our 
example, we will use a simplified but representative 
algothrim, much like the sensor detection format. In our 
example, the input range of 10 nm, from sensor detection 
range is within the maximum weapons range of 20 nm and the 
model "opens fire". From the CEP curve , figure CE 2, the 
initial CEP is 500 yards. Therefore if the opponets main- 
tain 10 nm separation, it may be expected that 50% of the 30 
rounds fired, or 15 rounds, land within 500 yards of the aim 
point or target. Again we simplify by assuming perfect aim, 

but inclusion of an aim error would be a straightforward but 
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forgone matter. The next problem is the assessment of the 
effect of the hits (if any) upon the target; the damage 
assessment . 



Damage Assessment 

There are, again many .methods of assessing possible dam- 
age inflicted upon a given target by a specific pattern of 
rounds. This model will use a percentage coverage approach. 
In this approach, the percentage of the CEP covered by the 
target (the length of the target divided by the CEP) will be' 
multiplied by the number of rounds landing (randomly) in the 
CEP (up to a maximum of one). This gives the expected num- 
ber of rounds landing upon the target. In normal practice, 
any one of several scientific techniques are used to make 
this number an integer. In the case of the model, we would 
use a random number generator with even or odds last digits 
determining round added or subtracted from the integer, 
respectively. In our example, we will assume a target 
length of 300 feet (100 yards). Our target "fills" 100/500 
or 0.20 of the weapons dispersion (CEP) so that 0.20 times 
15 rounds or 3 rounds are assumed to impact the target. 
Although the amount of damage inflicted by a single round is 
not independent of the impact point along the ships length, 
since the weapon dispersion is random, we will not address 
any difference in types of "hits". Therefore assuming a 
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mM- 



PERCENT DAMAGE 



DAI>1AGE ASSESSMENT 
(OF WEAPON B ON SHIP A) 




RANDOMLY DISTRIBUTED HITS ON SHIP TYPE K 
BY WEAPON B 



In our example, percent damage 
50 percent (plus) 

vessel forced to retire 



FIGURE CE-3 



random distribution of hits, random normal is acceptable, 
the type and effect of the damage might be determined by the 
model from a table or curve such as figure CE 3. Again the 
form of this curve is critical to the outcome of the con- 
flict, but not important to the development or execution of 
the model. Damage curves, such as figure CE 3, exist in 
several places where combat simulation has been conducted 
for decades. 

From our example damage assessment curve of figure CE 3, 
it is assessed that the 3 hits inflicted upon our target 
force it to retire. The implication is that the opponet is 
out of action for a period of time, but may return to action 
after some repairs. This type assessment (sunk, retire, 
etc) as results of specific damage accumulations, is very 
subjective but absolutely essential. It is important 
because it affects the operation of the opponet and thereby 
affect the actions and performance of both sides. This 
determination of elimination, temporary removal or degrada- 
tion of a unit is required to permit the model to conduct 
multi-unit assessments. 

To recap our example Our ship (P) detected opponet (K) at 
10 nm by sensor A. We engaged ship K at that range with 
weapons system B. In 1 minute of firing, we inflicted 3 
hits, forcing our opponet to retire. 
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This is interesting, but what was. ship K doing to us in 
the meantime. The answer is , exactly the same sorts of 
things we were doing to him. Obviously, certain actions by 
one opponet would be precluded from execution by the outcome 
of actions by the other. For example, if we suffered enough 
damage to be sunk before the 1 minute of firing was con- 
ducted, we could not have forced our opponet to retire. 
This brings up the problem of time versus event modeling. 
In the simple cases we will describe in this model each con- 
flict is being treated as a separate event. A more accurate 
depiction would permit the proportional sequencing of events 
to form a multi-state assessment. For the present, this 
model must address each change to the combat situation as a 
separate entity. 

Measure of Effectiveness 



In our example, ship P forces ship K to retire (turn 
back) with 50% damage to its systems. In turn, ship P suf- 
fered uncalculated damage in that same event. To state how 
effective P was against K, we must weigh the relative value 
of the two damage states of the opponets, and the actions 
expected to result from that damage. Thus our measure of 
effectiveness is the desired balance between the two differ- 
ent "combat effectiveness" menu branches of; A Surviving 
Capabilities (starting at menu page ) and B. Threats 
neutralized (starting at menu page ). This balance 
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must be established by the designer or user of the model. 
Most likely, a comparision of the different results of a 
number of opponets and in a number of different situations 
will be necessary. Methods of obtaining such a blending of 
seemingly conflicting outputs are offered in chapter 4. One 
additional note; even this extremely simple action sequence 
shows the advantage of internally consistant computer man- 
aged data bases over more conventional approaches. 
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CHAPTER 7 



COMBAT SIMULATION 

In this chapter we will trace an example of the combat 
simulation section module. We will simplify the case by the 
following assumptions: 

1. Both forces fully defined 

2. Single unit interaction 

3. Minimum additional external factors (weather, jamming) 

4. Fully operational units 

We have chosen, as our opponents, the FFG-7 frigate 
class of the U.S. navy as it might be expected to be config- 
ured today, and the Krivak II frigate of the Soviet navy. 
This choice, as made provides 



Approximate equality of 
size 
manning 
speed 

relative positon in "order of battle"; that is the rela- 
tive importance of the ship class in the countrys' total 
naval force. 
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These ships are designed for different primary warfare 



missions (FFG-7 = AAW, Krivak = ASW) . The 
and situation is described in table CS-1. 
strate the modules capabilities by explaining 



baseline units 
We will demon- 
its ability to 



1, Model the revelent parameters 

2, Be sensitive to changes in 
tional senario. 



of the specific situation 
unit configuration opera- 



Four alternative sets 
be attempted 



of combat effectiveness values will 



1. Baseline/no harpoon missiles on FFG-7 

2. Baseline/harpoon on FFG-7 

3. Baseline/units at 35 nm initial range 

4. Baseline/Units at 5 nm initial range 



The model would retrieve the baseline Krivak and FFG-7 
(Perry) from the threat (section lA menu ), and (sec- 
tion 5 menu ), respectively. See table CEl for high- 
lights. Thus there, will be four cases: Harpoon/35nm, No 
harpoon/35nm, Harpoon/5nm, and No harpoon/5nm. In all cases 
the units will be initially unaware of the adversaries pres- 
ence. They will, therefore, be employing an 
acoustic/electronic emission control scheme design intended 
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to optimize 
area. Table 



the 


respective 


units primary warfare 


CE-2 


shows these 


conditions . 



mission 
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1st CASE (No harpoon/35nm) 



In the initial circumstance we will assume, due to the 
range and partial emissions control posture, of both 

vessels, that neither ship "knows" that the other is in the 
immediate area. Thus, our situation would start with a 
detection of either unit by the other. 

1. Sensor performance (detection). 

Examining the two opponents sensors versus the appropri- 
ate signature levels, we might conclude the following: 



Air detection - none 

Surface (radar) detection - none 

Electromagnetic detection - potential soviet ECM vs 
SPS-55 Sc SPS-49: potential US ECM vs DON-2 (less than 

above) 

Acoustic detection - potential TACTAS vs soviet VDS; 
potential TACTAS vs soviet propulsion 

DOMINANT PROBABILITY 

1st assumed detection: TACTAS (convergence zone) on 

Krivak II at 28nm. (see chapter for assumed sensor per- 
formance algorithm: use max range of 90nm (2nd CZ)) Since 

no weapons are assumed to have range to exploit this 
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detection, situation continues until range closes to less 
than 15nm at which time FFG-7 launches standard missle in 
active/ARM (anti radiation missle) mode on Helo (lamps) sol- 
ution - note that FFG-7 class would/should attempt to main- 
tain maximum standoff if possible. Also note that TACTAS is 
not assumed to provide a fire control solution. The possi- 
ble firing doctrine might call for a single shot with ready 
second round fired upon damage assessment or unacceptable 
first weapons telemetry data. In this situation we are 
going to assume a hit based upon a positive random probabil- 
ity less than 1.0 and an out of action status to the Krivak 
with 40% total systems degradation. No damage or missions 
interference is assessed to the FFG-7. 

Considerations 

If the FFG-7 is not ARM configured and if LAMPS is not 
able/allowed to provide fire control solution or weapons 
delivery (not discussed), the situation, would most likely 
deteriorate to a gun fight. This assumed that the sometimes 
accredited anti-surface capability of the SSN-14 is inaccu- 
rate. In short, the margins of the weapons systems 
capabilities totally dominate our solution and must be 
defined/specified/agreed upon to validate to outcome or 
specify the solution. 
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CASE 2 Harpoon/ 35nm 



Same as Case 1 in initial aspects up to the weapons 
action (each side has the same sensors as case 1). Note, 
however, that probablistic models of detection or weapons 
performance might very well give a different function to the 
beginning of the problem). If, however, the situation is 
considerated constant, the following trends in performance 
might be expected; 



LAMPS still needed for over the'horizon fire control 
solution 

Harpoon missile deployable at opening (from initial 
detection range) target up to 55nm 

Lethality of harpoon much better than standard missile 

This model would more often assess a sunk Krivak, with all 
that event might imply to other actions. 

Outcome assessed 

Sunk Krivak, Undamaged FFG-7 
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Considerations: 



The possibility of damage to FFG-7 is much lower in this 
case that case 1. Thus it is a much better situation than 
Case 1 for FFG-7 although assumed outcomes might be consid- 
ered "equal". 
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CASE 3 No Harpoon/ 5nm 



In this instance it is assumed that the two units are 
together (that formal hostilities have not started) In this 
situation detection is assumed and valid fire control sol- 
utions are assumed to take equal amounts of time for both 
vessels. Even if the Krivak does not begin/or have a fire 
control solution before the FFG-7 the only appropriate weap- 
ons on both ships are the guns. Given the number /rate of 
fire/size of shell of the soviet guns over the U.S. gun the 
model would generate 3 hits in 20 seconds of firing (see 
example weapons system performance. Chapter with range of 
5nm and 8+nm) on the FFG-7, while the FFG-7 inflicted only 1 
hit upon the Krivak. Using damage assessment curves we 
might conclude outcome: FFG-7 out of action - 70% systems 
degradation. Krivak damaged - 10-15% systems degradation, no 
change in operations 

Considerations ; 

If LAMPS not airborne, damage potential to FFG-7 much 
higher. there is a very high potential advantage to unit 
initiating action due to in contact status of both units. 
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CASE 4 Harpoon/ 5nm 



The existance of harpoon does not change the outcome from 
CASE III. 



Outcome: Same as CASE 3 FFG-7 - out of action; Krivak 

- continues mission 
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Discussion 



The operation of this example points out two major con- 
tributions of this project to the naval ship design process. 

It provides a systematic method of providing consistent 
input to either an existing war gaming model or a model 
internal to this project. This is an essential element 
for naval ship design assessment. DEX provides extreme 
flexibility in this matter. 

This project permits the essential communication between 
the various design levels. In deriving our objective 
function (combat effectiveness), we have attempted to 
use the parameters important to each significan disci- 
pline involved in the naval ship design process. This 
should permit the participants to communicate, in common 
terms, with one another. In short, we have provide a 
common language (the model) to address the same question 
(What is the designs' combat effectiveness?). 
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SITUATION BASELINE 



SHIPS 



FFG-7 


Krivak II 


Dimensions 

L 135m 


23.4m 


B 13.7m 


14 . Om 


H 30m 

Propulsion 


31 . Om 


41,000shp gas turbine 

Speed 


80,000shp gas turbine 


30kts 


32 kts 


Helicopters 

2 X SH-2 (+) (300kts/l00mn) 

Weapons 

Guns 


None 


1. lx 77mm (86rpm/16km range) 

2. 1 30mm close in weapon 


2 X lOOmn ( ?rpm/ 



Torpedos 
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2x3 tubes 



8 tubes 



Missiles 



MK13 standard (AA/anti surface) 

( I0nm/55nm) 



SSN -14 (215mn) 
SAN 4 (8mn) 



ASW Weapons 



2 ASW mortars 



Sonar 

SQS-56 (medium frequency) 
TACTAS (passive array) 



Hull (Medium/low frequency) 
Variable depth sonar 
(Medium frequency) 



Electronics 

Radar 
Air search 

SPS49 HEAD NET "C" 

Surface Nav 

SPS 55 DON-2 



Fire control (Gun) 
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SPG-60 (Missile)^ Kitescreech (Guns) 

EYE Bowl SSN-14 

POP Group SAN-4 

Other Forces in Company (from threat/environment section lA) 
none none 



Weather 

Winds- 10 kts (from north) 
Seas - 3-4ft (n) 
Visibility - 13nm 
Precipitation - none 

Jamming - none 
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EQUIPMENT IN OPERATION/SIGNATURES 



FFG-7 


Krivak II 


Primary Mission 


Primary Mission 


(AAW Advance Escort) 


(ASW Patrol) 


Propulsion 16kts (patrol) 

SENSORS 

Sonars 


12kts (> cavitation speed) 


SQS-56-passi ve 


Hull mounted - passive 


Tactas - deployed 
Active Radars 


Variable depth - active 


49-A radiating/timeshare 


Head net C - standby 


55 - radiating 


Don-2 radiating 


Missile/gun radar- standby 


Missile/gun radar - standby 



ECM 

Auto search (passive) 


Search passive 
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Communications UHF/HF - 



EMCON (receive only) 



UHF/HF -EMCON (Rec 



(No short range communication techniques (visual hor 
due to single ship operations by both sides.) 



ive only) 



izon) 
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Chapter 8 
CONCLUSIONS 



This project offers "sometime original" by introducting 
a high level objective function; combat effectiveness; at 
the feasibility level of the ship design process. It fur- 
ther allows all participants to the process access to the 
assumptions used to arrive at that objective function. 

As discussed in chapter 1, the project team feels that 
the time is ripe to bring combat effectiveness into the ship 
design process. Improvements in gaming techniques and mod- 
eling have improved the ease of including combat effective- 
ness within the design process at the preliminary design 
stage. While it is a fact that there are potential improve- 
ments to many other facets of the process to be made by this 
approach, inclusion of the considerations raised by combat 
and combat operations should prevent over emphasis or out 
right suboptimization upon the noncombat considerations. 
The attributes and potential flexibility of DEX (see chapter 
2) are extremely important. The complexity of the ship 
design process demands maximum integration of the model and 
the user. It is believed that specification of the means or 
equipment too early in the process should be avoided. Such 
premature definition of hardware is a potential disruption 
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to the total process. In effect it is something done, in 
many cases, too early and it is the remaining portions of 
the design which suffer. In effect, when equipment is spec- 
ified to satisfy a need too early in the process, it may 
well be that the totality of its impact upon other later 
design stages may be missed. This model is believed to be a 
major attempt to include all significant determinants of 
naval vessel characteristics. Eventually all design proc- 
esses will, conceivably, be addressed by such a systems 
approach. The author feels that the techniques exist to 
permit this effort in the admittedly complex and involved 
ship design process. All the techniques proposed in this 
model are in practice, it is the integration of them under a 
capable software system which is a major contribution of 
this project. 



The impact of weapons/sensor performance upon ship 
design, is reflected in the sensitivity of the combat effec- 
tiveness of the design to them. The combat effectiveness 
figures and algothrims from chapter 7 are, therefore, a 
starting point for the ship systems designer. If they rep- 
resent important, even vital contributions to the 
effectiveness of a ship in combat, their accuracy is crit- 
ical. The authors believe that the naval architect/marine 
enginee ■ must become actively involved in the determination 
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and validation of any such techniques used to drive the 
design process. It is believed that such algorithms are 
extremely sensitive to minor variations in the system con- 
figurations. It will be one essential task of the naval 
architect/marine engineer of the future to provide the sci- 
entific interaction between such causes and their effects. 
It is this person who might, for example, best model a con- 
ceptual weapons effect upon an assumed hull structure to 
provide a curve such as the damage assessment curve (like 
figure CE 3 ) . 

The framework for a future naval ship design process mod- 
el has been presented. It will require validation and 
refinement. The next step in this project will be the 
development of the modules to support the framework. 
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APPENDIX 



This appendix consists, in order, of the menu all devel- 
oped menu strings listed below. The numbers refer to the 
sections defined in figure 1, chapter 1. 

Threat/Environment (la) Surface Threats (pages lal-i 
through lal-22) 

Non Combat Environment (lb) Command Control and Communi- 
cation (pages Ibl-i through lbl-14) 

Platform Parameters (3) Signatures (pages 3a-l through 
3b-21) 

Platform Parameters (3) Risk Factors (pages 3b-i through 
3b-5) 

Combat Effectiveness (7) All (pages 7-i through 7-7) 

Each menu section consists of a title page, a mapping of 
the section and pages of 1 to 4 specific menus. 



six menus have been left blank for the application pro- 
grammer in these ares to insert the appropriate information. 

For readability purposes, the eight letter abbreviations 
required by DEX have not been used in this appendix. 



SURFACE THREATS 
SECTION lAl 



lAl-i 



SURFACE THREATS 
Section lAl 



I 

A - 



I 

I 

I 

• B 



lAl(A) 



; pg 



Pg 8 



lAl(p) 
up 4 



IA1(D) 
up 3 



pg 5 



lAl(D) 
up 2 



1 

I 

I 

c - 



lAl(p) 

up 1 



lAl(B) 



D- 



lAl(C) 

pg 2 



Iai(d) 



IA1(CJ 
dovn I 



lAl(C) 

dovnz 






pg 11 





lAKp 
up 4 


PS 




lAl(E) 
up 3 



lAl(F) ' ‘ 
up 4 



lAl(F) 
UP 3 



lAl(G) 
up 4 



pg 10 



lAl(E) 

UP 2 
i_£g 6 



lAl(F) 
up 2 



IA1(E) 
up 1 



E - 



lAl(F) 
UP 1 



lAl(E) lAl(F) 



■ F- 



Pg J 



IA1(G) 
up 2 



>g 7 !_ 



lAl(G) 
UP 1 



lAl(H) 
UP 1 



down 
^ PS, 
lAl(E) 
down 3 



IZ 



lAKFi 
down 2 



lAl(E) 
down 4 



pg 1 j 



lAl(F) 
down 4 



G- 



lAl(G) 



H -I 



Pg A 



lAl(G) 

down! 




down 



IA1(E)| |IA1(F) 
down 6 down 6 



lAl(E) 
down 7 



pg 15 



pg lA 



lAl(G) 
down 5 



down 6 



lAl(G) 
down 7 



pg 16 



lAl(E) 
down 9 



pg 17 



lAl(G) 
down 8 



lAl(H) 
down 8 



pg 18 



lAl(G) 
down 10 



lAl(G) 
down 11 



Pg 19 



I 

lAl-ii 



lAl(G) 
down 12 






pg 20 1 


lAl(G) 

downld 


lAl(G) 

downl4 


lAl(H) 

downl4 




pg 21 


lAl(G) 

downlS 


lAl(G) 
down 16 


pg 22 



lAl(A) lAlXB) 




C4 O' 
CU 



IAl-1 



from pgl (B) from pg 1 (B) WEAPONS 



lAl(C) 



SURFACE PLATFORM 

WEAPONS 

TYPES 



GUN 

TORPEDO 

ANTI AIR MISSILE 
ANTI SURFACE MISSILE 
ANTI SUB MISSILE 



DONE 



m 

O, 



3 Q 



Q 00 



O, 

3 



in 



00 Oi 

^ k 

C4 

A 



O' CP 



04 

3 

Q 

iin 

' CP 
Q4 



pg 3 (E) 



lAl(D) 



ANTI SUB MISSILE 
TYPE 



u 



lAl(C) down 1 

SURFACE PLATFORI-1 

ELECTRONICS 

TYPES 



E CM 
RADAR 
SONAR 
RADIO 



DONE 



*1 



T 

C 

3: 

o 



m 





5 








0 


CN 


rH 


a 












5 1 


F 3 


m 


a 


' 5 






0 


0 




CN 


73 


73 


CP 


r-i 
















CP 








0 . 


CN 


m 






r-i 


CP 



CP O4 



IAl-2 



from pg 2 (C) E C M P9 2 (C) ANTI SUB MISSILE 



lAl(E) 



lAl(F) 



SURFACE PLATFORM 
WEAPONS SPECS. 

ANTI SUB MISSILE 




CN 

a. 

w 


SURFACE THREAT 
ANTI AIR WEAPON 
SIGNATURE TYPE 






VO * 




WARHEAD 




CT» 


RADAR 




\ 


a 




RANGE 


1 


e 

0 


HEAT (IR) 


FLIGHT SPEED 


in 

c 




ELECTRO MAGNETIC 


SIGNATURE 


o 






FIRING RATE 


tu 






GUIDANCE 


m 

rH 






MAGAZINE CAPACITY 


cn 

a 




SIGNATURE 


— 






DONE 




r 

r\ 


DONE 



lAl(E) down 1 '’3 

SURFACE PLATFORM 1 ^ 

ELECTRONICS SPECS. 

(ECM) 2 

TYPE 

DECOY MODE 
POWER LEVEL 
FREQUENCY 
BAND WIDTH 
SENSITIVITY 
PULSE WIDTH 



DONE 



IAl-3 



from pg 6 (F) up 1 “ from pg 6 (F) up 1 



lAl(G) 



SURFACE THREAT 
ANTI AIR MISSILE 
GUIDANCE SPECS. 

(ACTIVE) 

ACTIVE POWER 
FREQUENCY 
PULSE WIDTH 
ANTI JAM 



DONE 



lAl(G) down 1 



SURFACE THREAT 
ANTI AIR MISSILE 
GUIDANCE SPECS. 

I (SEMI ACTIVE) 



ACTIVE POWER 
DURATION 
FREQUENCY 
PULSE WIDTH 



DONE 



from pg 2 (C) from pg 2 (C) 



lAl (D) up 2 





ANTI AIR 
MISSILE TYPE 




r 




*pg 6 
(E) up 2 



lAl(D) up 1 





ANTI SURFACE 
MISSILE TYPE 




r 




'pg 6 
(E) upl 



from pg 5 (D) up 1 from pg 5 (D) up 



lAl(E) up 2 



CN 



SURFACE PLATFORM 
WEAPONS SPECS. 
ANTI AIR MISSILE 

WARHEAD 

RANGE 

FLIGHT SPEED 
SIGNATURE 
FIRING RATE 
GUIDANCE 

MAGAZINE CAPACITY 



DONE 



pg 6 (F) up 2 



lAl(E) up 1 

SURFACE PLATFORM 
WEAPONS SPECS. 

ANTI SURFACE MISSILE 



WARHEAD 

RANGE 

FLIGHT SPEED 
TERMINAL SPEED 
SIGNATURE 
FIRING RATE 
GUIDANCE 



DONE 



v£) 

CT> 

04 



*1 



C 

3 

O 

-a 



D1 

04 



lAl(F) up 2 

SURFACE THREAT 
ANTI AIR WEAPON 
WARHEAD TYPE 



HIGH EXPLOSIVE 
NUCLEAR 



lAl(F) up 1 



(N CN 



SURFACE THREAT 
ANTI AIR WEAPON 
GUIDANCE TYPE 



ACTIVE 
SEMI ACTIVE 
IR (HEAT) 



^pg 7 (G) 
" up 2 



a. 

p 

o 



Cn 

04 



c 

0 

a 






04 



O' 

04 



cn 

04 



cr> 

04 



IAl-6 



from pg 6 (F) up 2 frompg 6 (F) up 2 



lAl(G) up 2 



SURFACE THREAT ANTI 
AIR MISSILE 
WARHEAD SPECS. 

(HIGH EXPLOSIVE) 



WEIGHT TOTAL 
CHARGE WEIGHT 
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